Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000097_owner-urn-ietf _Sun Mar 30 13:58:21 1997.msg

Internet Message Format | 1997-04-01 | 8KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id NAA29473
    for urn-ietf-out; Sun, 30 Mar 1997 13:58:21 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id NAA29468
    for <[e-mail]>; Sun, 30 Mar 1997 13:58:17 -0500 (EST)
Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA26573  (mail destined for [e-mail]); Sun, 30 Mar 97 13:58:13 -0500
Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id MAA08161; Sun, 30 Mar 1997 12:58:06 -0600 (CST)
From: Daniel LaLiberte <[e-mail]>
Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id MAA00862; Sun, 30 Mar 1997 12:58:02 -0600 (CST)
Date: Sun, 30 Mar 1997 12:58:02 -0600 (CST)
Message-Id: <[e-mail]>
To: Leslie Daigle <[e-mail]>
Cc: Patrik Faltstrom <[e-mail]>, [e-mail]
Subject: [URN] Hierarchical ownership of name spaces
In-Reply-To: <[e-mail]>
References: <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Daniel LaLiberte <[e-mail]>
Errors-To: [e-mail]

Leslie Daigle writes:
 > Thanks, Dan, for a lot of comments [...]

You are welcome. Only trying to help.

 > > Who registers a name space if anyone can, in fact, resolve identifiers
 > > in the name space?  Does someone "own" the name space?  Some name
 >
 > Some entity is going to have to take responsibility for the namespace,
 > in one fashion or another. This is what, to my way of thinking, makes
 > URN namespaces more closely related to TLDs than to URL schemes.

The entity that takes responsibility for the definition of a name
space could be something like IETF or W3C that is a cooperative
effort, and part of that definition is how to delegate ownership to
authorities.  In fact, that is what you are trying to do in defining
the "URN" scheme.  On the other hand, any subtree of an HTTP URL is
setup and hopefully maintained by some entity,
e.g. http://union.ncsa.uiuc.edu/.  The 'edu' part is maintained very
publically, the 'uiuc' part much less publically, the 'ncsa' part even
less so, and I maintain the 'union' part myself.  So for both URNs and
URLs (the others are much like HTTP), there are some higher levels of
public cooperation, and lower levels that are more privately owned.

 > > What is so hard about managing the NID registration process?
 >
 > If by "NID registration process" you mean the process of registering
 > names within a NID (and not the process of creating a new NID),

Yes.  I suppose even that is ambiguous.  I meant to distinguish
name registration from name resolution.

 > I'd like to disagree here. It certainly _can_ be tricky, in a
 > namespace that is to guarantee global uniqueness and may have
 > multiple assigners.

I don't see what is so hard.  With multiple assigners, one mechanism
is to divy up the name space so that each assigner gets their own
unique part.  Another mechanism is to do it in a centralized manner
from one name space, and provide a simple service that increments a
number to generate a unique id, or if more meaningful ids are desired,
checks whether a particular id is already in use before authorizing
it.  The volume of registration requests is far below the volume of
resolution requests, so there is not really a scalability question to
deal with for most name spaces.  On the other hand, OMG might wish to
set up a name space for CORBA objects, in which case, many more
objects might need ids that will ever be used.  In that case,
delegation of the registration process works far better than
centralization.

 > I.e., the point is not to just find A way to
 > come up with unique names, it's to accommodate many namespaces as
 > HAVE this ability.

I don't understand what you mean by accommodate.  We don't have to
determine how NID authorities will in fact do their name registration
or resolution; they decide that themselves.  You, and others, want to
somehow *check* that the scheme they will be using will be following
the rules before you give them their NID authority.  I don't think
that checking is desirable.  You become a target for all kinds of
legal hassles.  Nor is it not practical since you would never know
that all of your criteria are necessary or sufficient?  The questions
will always outnumber the answers until you decide to delegate.

I want to set up a 'path' NID, and a 'http' NID.  Would you deny me?

 > If a namespace authority doesn't have the ability to manage its space,
 > we will wind up with multiply-assigned and otherwise bogus URNs.

And you want to impose on the naming authority that they somehow avoid
the hassles for the benefit of the world.  Doesn't the naming
authority have a strong enough incentive without any external
impositions?  Why will people choose to use URNs if they dont
understand the benefit of avoiding the hassles in the first place?
But if they do, then why do we need to step in to impose our vision of
order?

These are not easy questions and I don't mean to suggest they are.  At
issue is the very same kind of question people deal with when
considering whether welfare should be controlled by the federal
government or delegated to the states.  The best answer is usually
some kind of compromise.  My belief is that central control should
generally only be imposed where distributed control fails to be
sufficient.

 > >  >   - One URN should never be reused for a different resource (where
 > >  >     "different" is defined as in previous paragraph by the namespace).
 > >
 > > This is persistent registration.  Not at all difficult.
 >
 > I'm not sure I see what you mean here.  Someone who is proposing a
 > namespace must agree to not reassign URNs.  It's a requirement,
 > it's hard to enforce (my favourite example of "Today's weather in
 > Montreal" gif vs.  "Weather in Montreal on Mar 28/97" gif -- same
 > binary file, different object -- different names).

What I first meant by "not at all difficult" is that it is trivial to
create a new id that you know has never been used before.

But indeed, it becomes very complex to decide whether the unique id
rule is being obeyed.  In the general case, how do we decide whether
two objects are really the same and so can have the same name?  I
don't think we want to get involved in making all those decisions.  We
must delegate that decision.  Therefore, the problem of persistent
registration becomes simple: it's not our problem.

 > > There is another way to deal with all this much more simply: in a
 > > nutshell, delegate hierarchically and let each authority deal with
 > > meeting the requirements.  Anything more invasive is asking for
 > > trouble.
 >
 > Again, I think I've missed part of your point -- what is to be delegated
 > to whom in the hierarchy (and are we talking about the same hierarchy)?

The hierarchy I am talking about is the same one Karen mentioned in
her recent RDS requirements proposal.  It is a hierarchy of naming
authorities.  It can appear in an identifier between the first and
second colon as a hierarchical naming authority id, or after the
second colon as a hierarchical path, or before the first colon if we
allow hierarchical scheme names.  The hierarchy might not appear in an
identifier at all, but only be visible in a chain of resolution steps,
each one delegating to the next.

We should delegate to naming authorities the decision as to whether
they are following the naming rules to the extent that they feel is
justified and desirable to their users.

--
Daniel LaLiberte ([e-mail])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/